Object oriented programming, as is well known in the art, is used to design computer software that is easy to create, cost effective to modify, and reusable. Object oriented software provides data abstraction, which hides the physical representation of data within objects, and thus lessens the impact of changes when modifications are made to the software.
The Component Object Model (COM) for object oriented programming specifies how objects within a single application or between applications (e.g. client/server applications) interact and communicate by defining a set of standard interfaces. Interfaces are groupings of semantically related functions through which a client application accesses the services of a server application.
Object Linking and Embedding (OLE), such as OLE Version 2 by Microsoft Corporation of Redmond, Wash., is based in part on the Component Object Model and allows the creation of objects of different formats which operate on object data through defined interfaces, rather than on the applications responsible for the data. Using OLE, object data can be embedded within an object, or linked to it, so that only a reference to the object data is stored in the object. OLE enables developers to create sophisticated and extensible client/server applications.
At the heart of the OLE object system is the ability for a client object oriented application to have a reference to an object in a server object application, even though the two applications are not sharing computer process memory (e.g., computer memory, in the same operating system process space). In many client/server systems, both the client and server application exist within the same operating system process, and thus are able to share process memory. To allow an out-of-shared memory reference, two additional objects are created to maintain the object reference: an OLE proxy object in the client application, and an OLE stub object in the server application. An OLE channel is also created that connects the OLE proxy and stub objects. To the client, the OLE proxy object looks and acts just like the real object, because the OLE proxy intercepts and forwards all calls to the real object through the OLE channel to the OLE stub object. The OLE stub object in turn calls the real object. The communication between the OLE proxy and OLE stub is managed by an OLE channel object, which sends information between the client and server processes.
There are several problems associated with the existing OLE proxy/OLE channel/OLE stub model to maintain an object reference for client/server object applications that do not share memory. The OLE channel is not capable of sending information between client and server processes on different computers. In a distributed computing environment, client and server applications are typically located on different computers; therefore a client application cannot contain an object reference to a server application running on a remote computer. There is also no way to maintain object identity if an object reference was passed from a client object application to a remote server object application on a remote computer since object references are not known outside the local computer. This limits the ability of software developers to write distributed object applications using existing OLE and other object oriented frameworks.
The OLE proxy/OLE channel/OLE stub model also limits the ability of developers to create anything more than traditional two-tier client/server applications. If a client application could contain references to more than one remote server application (i.e., on one or more remote computers), then three-tier, four-tier, and potentially N-tier client/server layering could be accomplished. Three-tier client/server object layering is desirable for many business applications (e.g., a first tier providing user services, a remote second tier providing business services, and a remote third tier providing data services).
The inability to reference a remote object also limits the scope of a network client object application (e.g., an Internet object application), as only objects on the same computer can currently be referenced. The ability to reference a remote object (e.g., from a hypertext markup language (HTML) file, or in a HTML universal resource locator (URL)) would greatly enhance the variety and format of information (i.e. including audio, video, etc.) that could be accessed by a client network object application.
In accordance with the present invention, the ability to reference remote server object oriented applications on remote computers is achieved. The present invention provides a method for remote automation of object oriented applications. The remote automation method includes providing a two-way communications path between a client object oriented application on a client computer and one or more server object oriented applications residing on one or more remote computers, where the two-way communications path includes an object linking and embedding channel. The object linking and embedding channel allows object linking and embedding information (e.g., OLE information) to be sent to a remote computer. An object reference that is uniquely represented and identifiable by both the client object oriented application and the multiple server object oriented applications is accepted from the client object oriented application. The accepted object reference is passed over the two-way communications path using the object linking and embedding channel to the remote server object oriented application. The object linking and embedding channel allows object linking and embedding information to be sent to a remote computer with the minimum data manipulation or conversion. The remote object is returned to the client object oriented application from a selected server object oriented application.
Using the remote automation method, a client object oriented application can reference remote objects and remote object data on server object oriented applications running on one or more remote computers, provided the client and server computers are connected by a compatible computer network. The remote automation method provides multiple network connection possibilities including TCP/IP, PPP, and SLIP to connect the client and server computers.
The remote automation method is used to extend the OLE object creation process and modify OLE object data. Since only OLE object data is modified, the remote automation method is compatible with existing and previously written OLE client and server object oriented applications, and can be used without modifying these existing applications. In addition, the remote automation method maintains the identity of an object as an object reference is passed to one or more remote computers using the remote automation method.
With the remote automation method, an N-tiered client/server object application model is possible. In addition, object references to remote objects can now be added to network object applications (e.g., in HTML or HTML URLs), greatly enhancing the variety and format of information available to network object applications.
The remote automation method allows developers to quickly and cleanly create distributed client/server object applications, using a known and familiar object oriented programming environment (i.e., OLE), which decreases development time, and lowers overall development costs.